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DSN Command System configuration and functional operation are described. Voyager 
and Helios command operations are supported with DSS store-and-forward data handling; 
Viking and Pioneer are supported with the older, near-reaUtime data handling method. 


t. System Functional Description 

End-to-end command system operations are represented 
functionally in Fig. 1 . Command sequences for one or more 
spacecraft are generated and stored at a Mission Operations 
Center (MOC). Commands for a particular spacecraft are 
selected from the command files, formatted into messages, and 
stored for transmittal to a specified Deep Space Station (DSS). 
Command data are extracted from the messages received at the 
DSS and stored until radiated. Finally, the commands arrive at 
the spacecraft and are either executed immediately, or stored 
onboard for later execution. 

The functions of the DSN Command System in this process 
include the following: 

(1) Establishing the DSS configuration for the specified 
spacecraft. 

(2) Receiving and storing command data at the DSS. 

(3) Queuing command data to be radiated to the space- 
craft. 

(4) Radiating the command data to the spacecraft. 

(5) Monitoring and reporting system status and events. 

The Network Operations Control Center (NOCC) provides 
control and monitoring of the DSN Command System. 


Instructions from NOCC and command data from MOC are 
communicated to the DSS via the Ground Communication 
Facility (GCF) High-Speed Data Subsystem (GHS), as shown 
in Fig. 2. 


II. System Configuration 

A detailed diagram of the DSN Command System Mark 
III-80 is presented in Fig. 3. The Mark III -80 system configura- 
tion includes provision for uplink frequency control, as 
described in Ref. 1, via the DSN Tracking System, The 
Digitally-Controlled Oscillator (DCO) on the exciter assembly 
receives tuning parameters from the Metric Data Assembly 
(MDA). Manual operation of the DCO is also provided, for 
emergency backup. All other features of the Mark III-80 
configuration are the same as in the Mark III-78 configuration 
described in Ref. 2. 

During 1978, the DSS Command Processor Assembly 
(CPA) software program was upgraded to include the “store- 
and-forward” data-handling method and increased command 
storage capacity. The JPL Mission Control and Computing 
Center (MCCC) was reconfigured to provide the required 
processing functions to utilize the store-and-forward technique 
for Voyager and Helios spacecraft command operations. The 
Pioneer and Viking mission operations organizations chose to 
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continue to use the older, near-real-time method of command 
data handling. 

The CPA program (DMC-5084-OP-F; Rev. A) was trans- 
ferred to operations in November 1978 with several anomalies 
in the status reporting functions of the store-and-forward 
portion of the software. A new version of the program 
(DMC-5084-OP-G) was developed during 1979 and was trans- 
ferred to operations in April 1980, after extensive acceptance 
tests showed that the major anomalies were corrected. This 
program version is to become operational in early May after 
the Voyager Project Ground Data System (GDS) organization 
completes MCCC interface tests with the various Deep Space 
Stations. 

Some minor anomalies, related to local DSS displays, were 
identified in testing of the OP-G version of CPA software. 
Correction of those anomalies is planned in a program upgrade 
to be implemented in early 1981 . The upgrade is also intended 
to expand the store-and-forward capability to multimission 
apphcability for support of future missions. 

III. Pretrack System Preparation 

DSS pretrack operations performed by station personnel 
include initializing the CPA software for “phase 1” for 
“phase 2” operation so that the CPA will be prepared to 
recognize the content of the high-speed data blocks to be 
received from NOCC and the flight project command center. 
Phase 1 initialization is required for the older type (Mark 
III -74) command data messages; phase 2 initialization is 
required for the new (Mark III-78, store-and-forward) type. 
Additional on-site initialization inputs to the CPA specify the 
flight project name and the spacecraft identification number. 
These inputs cause the software to transfer a specific configu- 
ration and standards and limits table from disk storage to 
memory, and to configure the Command Modulator Assembly 
(CMA) and CPA according to the table. Changes may later be 
made by high-speed data messages from NOCC or by keyboard 
entries at the Data System Terminal (DST) in the station. 

Upon initialization, the CPA sends DSS Command Subsys- 
tem (DCD) configuration and status information across the 
star switch controller (SSC) to the DSS Monitor and Control 
Subsystem (Fig. 4) for inclusion in the monitor data blocks 
that are periodically transmitted to the NOCC tcT provide 
station status displays in the Network Operations Control Area 
(NOCA). The subsystem configuration and status information 
are also sent from the CPA to the DST for station display. 

Prior to the beginning of the scheduled spacecraft track, the 
control of the station command functions is transferred to the 
NOCC. Configuration and standards and limits are updated by 


transmission of high-speed data messages from the NOCC 
Command Subsystem (NCD) real-time monitor (RTM) pro- 
cessor. The configuration and standards and limits are derived 
from files maintained in the Network Support Computer 
(NSC). Spacecraft-dependent parameters, such as symbol 
period, subcarrier frequency, alarm limits, and abort limits, are 
established via these messages. After the proper configuration 
and standards and limits have been established, test commands 
are transmitted through the system to ensure that the system 
can accept spacecraft commands via high-speed data messages, 
temporarily store the commands, and confirm radiation. After 
NOCC operations personnel have established that the system is 
operating properly, the system control is transferred to the 
flight project’s MOC for transmission of actual spacecraft 
command sequences during the spacecraft track period. 

At the time for radiation of each command element, the 
CPA establishes the proper mode (see Fig. 5 for description of 
the various modes) and configuration of the CMA; then the 
command is transferred to the CMA for immediate radiation 
via the Receiver-Exciter, Transmitter, Microwave, and Antenna 
Subsystems. 

IV. Command Data Handling 

A. Phase 1 Method: Near-Real-Time 

With the CPA initialized for phase 1 operation, the data 
handling method is functionally the same as has been used 
since 1973. A command stack provides storage of up to four 
high-speed data blocks (stack modules) of command data. 
Each block may contain up to six command elements. Each 
command element consists of up to 71 bits of command data 
and, at project option, can be either timed or nontimed. Since 
the phase 1 storage is small, the MOC may need to update the 
CPA command stack frequently during a DSS spacecraft track. 

The top command element in the first stack module is 
eligible for radiation to the spacecraft. Nontimed commands 
are radiated immediately after eligibility. Timed commands are 
radiated after becoming eligible at the time specified in the 
high-speed data block. 

During command operations, events may occur in which 
high-speed data message transmission to the NOCC and MOC 
becomes necessary. The following events initiate message 
transmission: 

(1) Acknowledged receipt of a high-speed data block. 

(2) High-speed data block rejected by the CPA. 

(3) DSS alarm or alarm clear. 

(4) Response to a recall request. 
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(5) Confirmed command element. 

(6) Aborted command element. 


B. Phase 2 Method: Store-and-Forward 

The store-and-forward data-handling method associated 
with phase 2 initialization of the CPA utilizes the CPA disk to 
provide expanded storage of command data. This method is 
designed to allow mission operations to prepare large files of 
spacecraft commands in advance and then to forward several 
files to the DSS at the beginning of a DSS spacecraft track. 

1. Command files. Each file may consist of 2 to 256 
high-speed data blocks. The content of each data block is a file 
element. The first block in a file contains the header element 
and each remaining block contains a command element. Each 
command element may consist of up to 800 bits of spacecraft 
command data. Up to 8 files for a given mission can be stored 
by the CPA. Thus, the available storage is over 1.6 million 
command bits. 

The header element contains file identification information, 
file processing instructions, and a file checksum for error 
protection. Once generated (normally by project command 
generation software), the information is unchanged through- 
out the ground system. The file processing instructions include 
optional file radiation open and close window times, and an 
optional file bit 1 radiation time. File open and close window 
times specify the time interval during which command 
elements in the file may begin radiation (i.e., a mission 
sequence may demand that specific commands not be sent 
before or after a certain time). The bit 1 radiation time allows 
the project to specify the exact time at which the file is to 
begin radiation to the spacecraft. The file checksum is 
intended to provide error protection for the end-to-end ground 
command system. It is created at the time of file generation 
and is passed intact to the DSS. It adds reliability to insure 
that no data were dropped or altered in the transfer from one 
facility to another. 

The command elements each contain command bits, file 
identification information, element number, element size, and 
an optional “delay time” (interval from start of previous 
element). If delay time is not specified, the element will start 
radiating immediately after the end of the previous element. 

2. Receiving and storing command data at a DSS. Nor- 
mally, the files of commands to be radiated to the spacecraft 
are sent to a DSS at the beginning of a spacecraft track period. 
The first step in receiving and storing command data at a DSS 
is the process of opening a file area on the CPA disk at a DSS. 
The MOC accomplishes this by sending a header element. 


which serves as a file-open directive. After the CPA acknowl- 
edges receipt of the header element, the MOC sends the 
remainder of the file (up to 255 command elements) and 
follows it with a file-close directive. The CPA acknowledges 
the file-close instruction and indicates whether the file loading 
was successful or unsuccessful. If the file loading was 
unsuccessful, the acknowledge message contains the reason for 
the failure, and from what point in the file the command 
elements are to be retransmitted. When the file is successfully 
closed, the MOC may proceed to send additional files, up to a 
total of eight. 

3. Queuing the command data for radiation. After the files 
are stored at the CPA, the MOC sends one or more file-attach 
directives to place up to five file names in the radiation queue. 
The Mission Control Team determines in which order the files 
are to be attached. The order in which they are attached 
determines the sequence in which they will be radiated: that 
is, first attached, first to radiate to the spacecraft. 

4. Command radiation to the spacecraft. The first com- 
mand element in the top (prime) file in the queue begins 
radiation to the spacecraft immediately after attacliment or as 
soon as all optional file instructions are satisfied. The prime 
file status is defined to be active when the first command 
element begins radiation. Upon completion of radiation of the 
first command element, the second command element begins 
radiation either immediately or when the optional delay time 
has been satisfied. The process continues until all command 
elements in the file have been radiated. After the first file 
completes radiation, the second file in the queue automatically 
becomes the prime file and the command radiation process is 
repeated. After the second file completes radiation, the third 
file becomes prime, etc. This process is repeated until all files 
in the queue are exhausted. The MOC can attach new files to 
the queue whenever space is available. 

Confirmations of command element radiation are reported 
in event messages to the MOC and NOCC once per minute, or 
after five elements have been radiated, whichever occurs first. 
If a command element is aborted, an event message is sent 
immediately. 

5. Additional data processing. The foregoing descriptions 
of the functions of storing the command files at a DSS, 
attaching the files to the queue, and radiating the commands 
to the spacecraft assume nominal-standard operation. Addi- 
tional data processing functions are provided for worst-case 
conditions, nonnominal operations, and failure recovery. 

a. File erase. The capability exists to delete a file from 
storage at the CPA. This erase function can be accomplished 
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either locally at a DSS or via a high-speed data message from 
the MOC. 

b. Clearing the queue. As previously stated, the order of 
file radiation to the spacecraft is dependent on the order of 
files in the queue. To rearrange the order, the MOC must send 
a dear-queue directive, followed by file-attach directives in the 
desired order. 

c. Suspend radiation. If the Mission Control Team desires 
to stop command radiation, a suspend message can be sent 
from the MOC. This message stops command radiation to the 
spacecraft upon completion of the current element. The file 
status then changes from active to suspended. 

d. Resume command radiation. To restart radiation of a 
suspended file (either suspended intentionally or from an 
abort), a message can be sent from MOC to resume radiation at 
a specific element in the file. 

e. Command abort. As each command bit is radiated to the 
spacecraft, numerous checks are made to insure validity of the 
command data. If a failure is detected during radiation, the 
command element is aborted, and the prime file status is 
changed from active to suspended. Optional methods of 
treating an abort are provided. If one or more automatic 
recovery attempts have been specified in the standards and 


limits, the CPA will try to resend the command element, or 
else radiation will be terminated until operator intervention 
occurs. 

/ Close window time override. The close window time 
(previously discussed) can cause an actively radiating file to 
become suspended. If this occurs, the MOC can send an 
override message that directs the CPA to ignore the close 
window time and proceed to radiate the complete file. 

V. Data Records 

All high-speed data blocks received by the CPA and all 
high-speed data blocks sent from the CPA are logged at the 
DSS on the Original Data Record (ODR) by the Communica- 
tions Monitor and Formatter (CMF). The CPA has the 
capability to record a temporary ODR on disk, if the CMF 
ODR is disabled. 

High-speed data blocks from all DSS are recorded at the 
GCF central communications terminal (CCT). Command 
system high-speed data, blocks from a Mission Operations 
Center to the DSS are also recorded at the CCT. 

The DSS original data records and the CCT recordings 
provide information for fault isolation in case problems occur 
in the command system operation. 
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Fig. 1 . End-to-end command data flow— typical storage times 



Fig. 2. Facilities that participate In command operations 
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